Currently, path-tree with strict mode. /users and /users/ as different.

In my practice, when nested routes,

/users is a prefix path,
/users is a route.
/users/:name is another route.

We can do something about the path.

    pub fn nest<S>(self, path: S, router: Self) -> Self
    where
        S: AsRef<str>,
    {
        let mut path = path.as_ref().to_string();
        if !path.ends_with('/') {
            path.push('/');
        }

        match router.routes {
            Some(routes) => routes.into_iter().fold(self, |router, (mut sp, route)| {
                let is_empty = sp.is_empty();
                sp = path.clone() + &sp;
                if is_empty {
                    sp = sp.trim_end_matches('/').to_string();
                }
                router.route(sp, route)
            }),
            None => self,
        }
    }

router.nest("/users", Router { routes: vec![("", handler), (":name", handler)] })  

The above code is from Viz, I'm refactoring it and haven't opened it up yet.

Currently, path-tree with strict mode. /users and /users/ as different.

This would preserve that. As far as I can tell the only thing this changes is allowing "" as a path, which like you say would be different from "/".

router.nest("/users", Router { routes: vec![("", handler), (":name", handler)] })

Hmm I don't particularly like the idea of special casing this, I'd prefer this to be more general and done at a higher level of abstraction. Basically:

1. Define a route/application trait/API. In the Python world, that's ASGI.
2. Make a type/class that wraps the low level router (PathTree) and implements that interface (Python example)
3. Routers match a path, strip it from the remaining path and forward the request to a route. If that route happens to be a router, it can do further matching based on the remaining path. Otherwise if it is an endpoint, it can check the HTTP method or call into the user's code.

Now this does mean a small performance hit since you're splitting up the tree into two, but since it naturally maintains a tree-like structure if the path prefixes are long it could even be a performance win (I think) over grabbing the nested router's routes and adding them to the outermost router's tree. It also provides more flexibility, composability and decoupling.

Ignoring a bunch of details, here's my super clunky and wrong Rust version of the idea

#[derive(Clone, Debug)]
pub struct Request {
    raw_path: String,
    remaining_path: String,
}

pub trait Route {
    fn handle(&self, request: Request) -> ();
}


struct Router {
    tree: PathTree<Box<dyn Route>>
}

impl Route for Router {
    fn handle(&self, request: Request) -> () {
        match self.tree.find(&request.remaining_path.to_owned()) {
            Some((route, params)) => {
                route.handle(
                    Request {
                        raw_path: request.raw_path,
                        remaining_path: request.remaining_path.strip_prefix("the matched path").unwrap().to_string()
                    }
                )
            },
            None => panic!("404")
        }
    }
}

Thank you for reviewing and merging! Do you plan to cut a release with this change?

Bumped in v0.3.1.

@adriangb hi, I opened viz-v0.2.0-alpha. If you are interested, you can take a look at the router implementation.

Currently, I am currently writing docs.

@fundon this seems to have been regressed when you did the rewrite. Do you think the new version could also support this behavior?

@fundon this seems to have been regressed when you did the rewrite. Do you think the new version could also support this behavior?

Currently, not accept empty string, I thing we can remove the limit.

Yeah that would be great! I gave it a bit of try and couldn't immediately figure out how to get it working without breaking other things, but that's probably just because of how bad my Rust is 😅